The legacy transmission control protocol (TCP) relies upon sender-based congestion control, which presumes all losses are caused by congestion of a network, e.g. congestion at network routers. Some networks experience only congestion-based loss because of very “clean” communication links that are virtually lossless. TCP assumes that all packet loss is caused by congestion. Therefore, in accordance with TCP, network hosts will reduce transmission rates in response to any packet loss in order to combat the perceived (and perhaps non-existent) congestive packet loss.
A client computer and a server computer may exchange data in accordance with TCP. Each packet is marked with a packet sequence number. Each of the client and the server acknowledge reception of a new packet when the sequence number is one unit larger than the previous packet. However, a computer can detect a lost packet, e.g. due to congestion, when the packet arrives out of sequence, because the sequence number of a next packet will be two or more units larger than the most recently received in-sequence packet. That is, the lost packet will not arrive, so its sequence number will be skipped. In this case, the receiving computer will send a duplicate acknowledgement of the most recently received in-sequence packet. The transmitting computer, upon receiving a duplicate acknowledgement, will retransmit the lost packets and reduce its transmission rate to reduce the perceived congestion. In this manner, TCP may be considered a server-side congestion control protocol, because it is the “server,” or transmitting computer, that determines that transmission rates must be reduced to avoid packet loss due to congestion.
Some networks, however, also experience corruptive loss. Networks operating over a radio transmission, for example, may regularly experience packet loss due to corruption of packets. In the face of corruptive loss (such as loss caused by underlying communication-link issues), network elements may still reduce transmission rates, in accordance with TCP. However, reducing the transmission rate will not correct the underlying problem of corruptive loss. Therefore the legacy TCP correction scheme of reducing transmission rate may lead to sub-optimal data-transfer rates.
Certain extensions to legacy TCP, such as explicit congestion notification (ECN), have been implemented to overcome this limitation of TCP. For example, in accordance with ECN, an intermediate network device may set flags in a packet IP header to indicate the existence of congestion at the intermediate network device. When the packet reaches its final destination, the destination computer may propagate the ECN flags back to the source of the packet and as a result the source may reduce its transmission rate. ECN, however, may not be feasible in environments where strict packet integrity is enforced by data-security mechanisms. Strict data-security mechanisms may prevent the ECN flags (or any in-transit packet markings) inserted by an intermediate network device, from reaching the destination computer as well as preventing propagation of the ECN flags back to the source.
Alternative reliable transport protocols, such as the Stream Control Transmission Protocol (SCTP), can transmit data over two network paths, but require recompilation of existing applications in order to make use of this feature for applications that bind to a specific IP address.